--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi EC,
>
> Velocities, Accelerations, and Jerk settings relate to the desired trajectory of motion.  It doesn't matter if your system is closed-loop or open-loop (from KFLOP's perspective).  You can set the Max Velocity, Acceleration, and Jerk on the Step Response Screen and test the motion.  With an open-loop systemoperative the Step Response Screen will still move the motor and plot the trajectory.  But you will not be able to plot how the motor actually moved unless you have feedback.  You will need to watch/listen to the motor, look for any amplifier faults and so forth to see how well it is working and what your limits are.  The idea is to do all the configuration and testing in KMotion.exe before trying to run GCode or other applications.
>
> These parameters should already be included in your Initialization C Program with something for each axis like:
>
>     ch0->Vel=40000;
>     ch0->Accel=200000;
>     ch0->Jerk=4e+006;
>
> This Flash Video may help:
>
> http://dynomotion.com/Help/FlashHelp/Parameters/index.html
>
> For your X axis it seems you have fairly high Acceleration set for the Trajectory Planner.  75 in/sec2 which is aoperativebout 0.2G.  If this is reasonable for your system this would be:
>
> 75 in/sec2 x 50800 counts/in = 3.81e6 counts/sec2
>
> A Jerk setting that would apply this Acceleration in 1/20th of a second would be 7.62e7
>
> Regards
> TK
>  
>
>
>
>
> ________________________________
> From: ericncn <ericnc@...>
> To: DynoMotion@yahoogroups.com
> Sent: Tuesday, July 23, 2013 4:09 PM
> Subject: [DynoMotion] more trouble [was: Re: lookahead problem (I believe)]
>
>
>
>  
> Thank you for the explanation, I believe I understand... jerk limited motion is better but not always applicable so you also have another method and you use either one depending on which is applicable. OK.
>
> My system has the servo loop managed by the motor drives (the KFLOP doesn't read the encoders - yet), still I tried the Step Response Screen but looks me it doesn't do anything.
>
> Could you suggest me values for Jerk and Acceleration that could be reasonable in my case AND tell me where do I set them? Do I have to add some C-code in my axes init procedure?
>
> Thank you
> EC
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi EC,
> >
> > There are two types of motion used in KMotionCNC/KFLOP.  Jerk limited motion (3rd order - "S" curve Velocity) and unlimited Jerk (2nd order - Trapezoidal Velocity).   Our Trajectory Planner isn't capable of limiting Jerk when performing coordinated motion through complex paths with look ahead (although we believe we have one of the best Trajectory Planners).   G0 Rapids, Jogging, Homing, Probing, use Jerk Limited Motion.
> >
> >
> > Jerk limited motion is like applying the gas/brakes in a car gradually vs instantly.  Jerk limited motion will be much smoother than unlimited Jerk motion but will take longer using the same max acceleration and velocities.  However it is usually possible to use higher accelerations and Velocities with such that the net result is smoother and faster than unlimited Jerk settings.
> >
> >
> > Please set the Acceleration and Jerk settings for the axis parameters in KFLOP to reasonable values.  They can be viewed and tested on the Step Response Screen.  Most systems work best with the Acceleration ramped up over a period of about 1/20th of a second.  Faster than this is much like the shock of unlimited Jerk.  Slower than this will take excessively long to accelerate.  But every system is different.  Setting the value of Jerk to 20X the value of acceleration will do this.
> >
> > HTH
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: ericncn <ericnc@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Tuesday, July 23, 2013 2:12 AM
> > Subject: [DynoMotion] more trouble [was: Re: lookahead problem (I believe)]
> >
> >
> >
> >  
> > Hi Tom,
> >
> > regarding #2 I'm a bit confused.
> > Yes, I've listed the parameters that I've changed in the Trajectory Planner (resolution, speed, acceleration) while I've left "Jerk" at its default value (you asked my settings for Resolution, Speed, Acceleration, and Jerk).
> > Do you mean the feedhold isn't using the values specified in the trajectory planner and there's another place where I have to set those same values again? Where?
> > And, pardon me, why?
> > What's the benefit in specifying two different accelerations for trajectory planner and feedhold?
> > Should I set a higher acceleration for the feedhold than I set in the trajectory planner?
> >
> > regarding #4, the G56 is part of the issue.
> > If you look at the DROs while executing, at the beginning you'll see the values in G56 coordinates while the mill is moving in G56 coordinates (this looks OK to me).
> > But at a certain point the numbers on the DRO switch to G54 coordinates while the mill is still doing its job in G56 coordinates which is very bad in my opinion:
> > if the DROs are meant to give a feedback about the machining being done and this feedback suddenly jumps to values different than expected, I rush to the emergency stop....
> >
> > Thank you,
> > EC
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi EC,
> > >
> > > Regarding:
> > >
> > > #1 - good
> > >
> > > #2 - sounds like too low of Jerk as previously stated.  You must configure Jerk to a reasonable value for your system.  The values that control the feedhold rate are the Acceleration and Jerk values in KFLOP in units of counts.  Not the Trajectory Planner parameters which it appears you have listed.   All the current Velocities, Accelerations, and Jerks are used to compute a reasonable value of time to "wind down" time while following the original motion of all axes along the original path.  If you configure KFLOP for a huge amount of time to decelerate, but configure the Trajectory planner to change directions quickly, the result will be the behavior you describe.
> > >
> > > But you bring up an interesting point.  An analogy might be that you are turning a crank on a complex machine with a lot of moving parts.  And you are told to stop the machine by very gradually reducing the speed you are cranking so that nothing in the machine gets shocked or broken.  But then just as you begin slowing the speed of the crank you notice that surprisingly everything in the machine suddenly came to a stop.  It should be then possible to just suddenly stop turning the crank!  
> > >
> > >
> > > #3 - I guess it isn't repeatable.
> > >
> > > #4 - I ran that a few times and I don't know what I'm supposed to be looking for?  I'm not sure if the G56 is important.  I tried putting the numbers in the comment as a G56 offset.
> > >
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: ericncn <ericnc@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Monday, July 22, 2013 9:58 AM
> > > Subject: [DynoMotion] more trouble [was: Re: lookahead problem (I believe)]
> > >
> > >
> > >
> > >  
> > > Hi Tom,
> > > answering all the questions orderly + adding one more issue:
> > >
> > > 1) Yes, the new patch works. Now the spindle doesn't stop spinning while the mill is machining. Thank you!
> > >
> > > 2) I meant that the Feedhold is decelerating with a different (lower) acceleration than defined in my settings.
> > > I let Jerk as default after reinstalling from scratch.
> > > The settings of the other parameters are like follow:
> > > X axe 50800 4 75
> > > Y axe 50800 1 30
> > > Z axe 101600 0.25 30
> > >
> > > If you run this:
> > >
> > > G40 G90 G17 G21
> > > F6000 G01 X100
> > > X-100
> > > X0
> > > M30
> > >
> > > you can see the mill table changing direction abruptly from left to right. But if you try feedhold it takes like a couple inches movement before it stops.
> > >
> > > And, even more crazy, if you hit the feedhold button when it's approaching 100 (or -100), it starts decelerating, IT REACHES THE DESTINATION, INVERTS THE DIRECTION, AND COMPLETES DECELERATION WHILE GOING IN THE OPPOSITE DIRECTION! (!!!)
> > >
> > > If you think about it this is really crazy as, in order to invert direction, there's a moment where the speed is already zero!!
> > > So it accelerates again in the opposite direction and then "completes" the deceleration!
> > >
> > > 3) that was a G-code program I've run dozens of times with KmotionCNC 430 in the past months, before I had to replace the spindle motor.
> > > Now I finally installed a new spindle motor, installed patched 431, did all the safety checks I could (as you can see from my previous emails), manufactured one part, everything OK,
> > > then I put a new workpiece on the fixture, restarted the program with confidence, and immediately got a crash because the Z was too low.
> > > I barely had time to realize it and the feedhold didn't help.
> > >
> > > I really don't know what happened. I don't say it's necessarily the software, I just can't figure out any reason it happened. I had run that program dozens times, and I had just successfully made another part with it
> > >
> > > 4) new problem I've found today.
> > > Try this:
> > >
> > > G40 G90 G17 G21
> > > G56 ( -122.463, -9.807, -74.023)
> > > S150 M3
> > > F500 G01 Z5
> > > F100 G01 Z1
> > > F20 G01 Z0
> > > F1 G01 z-0.02
> > > F500 G01 Z20
> > > M30
> > >
> > > keep watching the DROs while the program is run, and you'll see...
> > >
> > > Thank you,
> > > EC
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi EC,
> > > >
> > > > I posted earlier but it hasn't shown up yet on the Yahoo Group.ÃÆ'‚  Here is a copy:
> > > > The patch has been changed to flush any pending motion and wait for the
> > > > motion to be completed before calling the PC program.ÃÆ'‚  Please
> > > > re-download the patch and see if it solves that issue.
> > > >
> > > > The Feedhold should decelerate based on your Acceleration and Jerk Settings,ÃÆ'‚  There should not have been any changes. What are your settings and how far is it taking to stop?ÃÆ'‚  (Resolution, Speed, Acceleration, and Jerk).
> > > >
> > > > Is the Z height issue repeatable?ÃÆ'‚  Is it different than your previous version?
> > > >
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > > ________________________________
> > > > From: ericncn <ericnc@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Sunday, July 21, 2013 1:05 PM
> > > > Subject: [DynoMotion] more trouble [was: Re: lookahead problem (I believe)]
> > > >
> > > >
> > > >
> > > > ÃÆ'‚ 
> > > > The same also happens with M2 and M30.
> > > > They have the effect to stop the spindle way BEFORE the program has reached the end i.e. whilst the mill is still inside the workpiece and the axes are moving. This is very bad.
> > > >
> > > > Also, the feed hold (yellow triangle button) stops axes motion with a too low deceleration i.e. if I click feed hold when the axes are moving quickly, they go on moving for too long distance.
> > > >
> > > > Also, I tried to make some work and the second time I've run the same G-code program it set the Z height much lower than previous time and the mill crashed in the workpiece.
> > > > Broken the endmill, the ER collet, the workpiece, the precision ground ball screw of the Y axe now makes bad noise, and I suspect there's more damage I haven't found yet.
> > > >
> > > > Maybe this 431i version was not meant to be used in production?
> > > >
> > > > EC
> > > >
> > > > -- In DynoMotion@yahoogroups.com, "ericncn" <ericnc@> wrote:
> > > > >
> > > > > Now that I've finally implemented the M3/M4/M5 codes, I've stumbled in a new problem.
> > > > >
> > > > > It looks like these command when invoked within a G-code program, are executed EARLIER than expected. At least 1 step before.
> > > > >
> > > > > e.g. if I wrote something like:
> > > > >
> > > > > 1) G1 ......
> > > > > 2) G1 ......
> > > > > 3) M3
> > > > > 4) G1 ......
> > > > >
> > > > > and hit the "run" button, the command n. 3) is actually executed BEFORE command 2)
> > > > >
> > > > > Everything works as expected if I run it step by step instead, hence I suspect that's something having to do with the lookahead.
> > > > >
> > > > > This is a dangerous problem... imagine one inserted an M5 (stop spindle) after the last machining step (like I did) and when running the program the spindle stopped rotating while the endmill was still moving inside the workpiece!!!!
> > > > >
> > > > > EC
> >
>